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Description 

FIELD OF THE INVENTION 

5 [0001] The present Invention relates generally to a system and method for transmitting digital information, and more 
particularly, for facilitating transmission of IP data over digital MPEG networks. 

BACKGROUND OF THE INVENTION 

io [0002] Communication in modem society has been greatly enhanced by the advent of such widespread data networks 
as public telephone systems, the Internet (including the World Wide Web) and cable and satellite television systems. 
An important protocol for transfemng information, for example through the Internet, is the well-knpwn Internet Protocol 
(IP). However, for cable and satellite systems, an important mechanism is the Moving Pictures Expert Group (MPEG) 
transport stream (/.e., MPEG-2). To facilitate interoperability, standards have been developed that specify how IP da- 

15 tagrams are mapped onto MPEG-2 transport packets, as seen be reference to ATSC Data Broadcasting Specification, 
ATSCT3/S13DOC. 010 DVS-161, R3ev 1.0 draft, March 31, 1999. and Digital Video Broadcasting (DVB): DVB Spec- 
ification for Data Broadcasting. EN 301 192 v1.2.1 (1999-01) (available at http://www.etsi.org ). According to the DVB 
standard, a complete IP datagram 10. as shown in Figure 1. if greater than 1008 bytes In length, is fragmented into a 
plurality of IP datagram fragments 12^. .... 12^. Each IP datagram fragment 12i 12^ is then encapsulated into a 

20 DVB-MPE datagram section 14^ 14^. (a "DSM-CC" section according to the ATSC standard). Each DVB-MPE 

datagram section is then, itself, broken up and carried in a payload portion of an MPEG-2 transport packet 16^ 16i. 

16i+i 16n. which packet is limited to 188 bytes. 

[0003] Although fairly involved, as shown in Figure 1. interoperability between IP and MPEG is both possible and 
desirable, since it provides an opportunity for cable and satellite system operators to provide enhanced services to 

25 subscribers. As one example, the Advanced Television Enhancement Forum (ATVEF). a cross-industry group, has 
specified a standard for providing enhanced television programming which uses Internet technologies, as seen by 
reference to Enhanced Content Specification, Advanced Television Enhancement Forum (ATVEF). Version 1.1r26 
(hereinafter "ATVEF document"). The ATVEF document discloses an ATVEF binding, which is a definition of how 
ATVEF will run on a given network (/.©.. the ATVEF binding provides the "glue" between the ATVEF specification arid 

30 a given network specification). The ATVEF document further discloses that the binding to iP is the reference binding 
because IP is available to run over virtually any kind of network. 

In addition, it is contemplated that ATVEF data may be distributed using an IP multicast mechanism, as described in 
RFC 1112. Thus, while IP can be carried on MPEG networks according to the ATSC or DVB standards referred to 
above, for example to implement ATVEF. there are a variety of shortcomings. 

35 [0004] One shortcoming is inefficiency Facilitating IP protocol carriage within MPEG transport streams according to 
the above-referenced standards does not optimize the processing associated with the mapping of IP datagrams onto 
MPEG-2 transport packets. Specifically, a set-top box (STB) or the like at a receiving end conventionally must receive 
a plurality of MPEG transport packets to put the DVB-MPE sections back together and parse the result to determine 
the destination, or worse yet, reassemble the fragmented IP datagrams to determine the destination from the address 

40 field. The STB must then determine whether to pass the captured IP datagram on to higher layers for further processing. 
Due to the continuous flow of IP datagrams, for example in an IP multicast scenario, the parsing and reassembly 
process may use a significant amount of processing resources (e.g.. CPU cycles, memory, etc.). This usage reduces 
the overall performance of the STB regardless of whether an application running on the STB has established a con- 
nection or not (i.e., established a need for the IP datagrams). 

45 [0005] One approach taken in the art, disclosed in M. Dolan, A Discussion of A TVEF and Its Possible Bindings Onto 
The ATSC Transport, Version 1.0. Draft 3. February 16. 1999. to address the IP-to-MPEG binding, proposes utilizing 
an MPEG system data construct (/.e.. referred to as a Virtual Channel Table) to explicitly indicate to the receiving 
terminal (e.g.. STB) every ATVEF data Packet Identification (PID), a data component of an MPEG service. This ap- 
proach, however, introduces undesirable coupling and other inefficiencies. For example, this approach restricts the IP 

50 datagrams to a single system, that is. the VCT cannot readily span multiple systems since VCTs are system specific 
(homogeneous, i.e., several cable systems/headends, or heterogeneous, i.e., across satellite and cable). 
[0006] There is therefore a need to provide an improved method and system for transmitting IP data to a subscriber 
that minimizes or eliminates one or more of the shortcomings set forth above. 

[0007] WO97/2041 3 discloses a packet switching system enabling, for example, TCP/IP traffic to be transmitted via 
55 an MPEG data stream. The receiving device for the TCP/IP traffic is allocated a temporary. IP address and part of that 
address is used as the packet identifier (PID) for the MPEG transport packets. 
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SUMMARY OF THE INVENTION 

[0008] One advantage of the present invention is efficiency. If an application running on a set-top box has not es- 
tablished a connection to receive IP data, then there is no need to fonward the IP datagrams, and. more importantly, 

5 there is no need to perform the reassembly and syntax parsing referred to in the Background to reconstruct the IP 
datagrams. When a connection has been established, however, a descriptor is sent to the set-top box {in a PMT) that 
associates a data stream and a MAC destination address. The Invention allows earlier filtering to determine whether 
certain MPEG data streams contain the desired IP data. The Inefficiency and unnecessary usage of resources of 
t conventional approaches. is eliminated with the present invention. 

10 [0009] A method is provided for facilitating delivery of content in a content data stream to a terminal. The method 
includes three main steps. The first step involves generating a descriptor for the content data stream that includes a 
destination address. The next step involves transmitting the descriptor to the terminal in a Program Map Table (PMT). 
The third step involves locating the content data stream at the terminal using the destination address in the descriptor. 
[0010] In a preferred embodiment, the content comprises Internet Protocol (IP) datagrams where the content data 

t5 stream is transmitted to the terminal in a Moving Pictures Expert Group-2 (MPEG-2) transport stream. In a still more 
preferred embodiment, the content complies with an Advanced Television Enhancement Forum (ATVEF) specification 
for advanced television programming. In a still further preferred embodiment, the ATVEF data is configured to enhance 
an audiovisual service also provided to the terminal over the MPEG transport stream. The invention thus enables 

delivery of enhanced audiovisual services. 

20 [0011] The descriptor enables earlier filtering, without which the terminal, which may be a digital consumer terminal 
(OCT) would have to receive and examine a plurality oflDVB-MPE or DSM-CC sections, or worse, parse these sections 
to reconstruct the IP datagram. This would be needed in order to examine the destination/address field within the 
datagram to determine whether the reconstructed datagram should be passed on to higher layers (i.e.. If an application 
had already established a connection with similar attribute values, e.g.. IP multicast address). The invention minimizes 

25 the impact on the terminal's resources, as well as enables an efficient association of multiple data streams to accompany 
the audiovisual service. The invention enables the service definition (i.e.. contained in the descnptor) to be self con- 
tained, and thus be adaptable for use over multiple systems, since the PMT Is not system specific like a Virtual Channel 

[0012]'^?n apparatus for generating the descriptor, and a terminal configured to recognize and use the descriptor are 

30 also presented. . . 

[00131 Other objects, features, and advantages of the present invention will become apparent to one skilled in the 
art from the following detailed description and accompanying drawings illustrating features of this invention by way of 
example, but not by way of limitation. 

35 BRIEF DESCRIPTION OF THE DRAWINGS 
[0014] 

Figure 1 is an illustration of a prior art mapping scheme for mapping IP datagrams into MPEG transport packets; 
Figure 2 is a block diagram view of a system for local (headend) IP data insertion according to the invention; 
Figure 3 is a simplified block diagram view of protocol stacks associated with various components for supporting 

the present invention; . ^ . . j- * 

Figure 4 is a simplified, block diagram view of a Program Map Table (PMT) containing a descriptor according to 

the present invention; and 

Figure 5 is a simplified flowchart of the processing that occurs in a set-top box (terminal) in accordance with the 
present invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

50 [001 5] Referring now to the drawings wherein like reference numerals are used to identify identical components in 
the various views. Figure 2 is block diagram of a system 20 in accordance with the present invention. System 20 is 
configured for allowing or facilitating a subscriber 22 to access Internet Protocol (IP) data by way of a terminal 24 
(labeled in the Figure 1 as ASTB for Advanced Set-Top Box). The IP data may be ATVEF data, used to provide enhanced 
audiovisual services, perhaps being displayed on a display 26 connected to terminal 24. System 20 illustrates the 
55 various equipment involved in inserting IP data into MPEG data streams at a local or headend location. In an alternative 
embodiment (not shown). IP data may be inserted at a National Access System (NAS) and broadcast to a population 
of terminals 24. Figure2furtherillustratesa variety of IP data sources such as a network server 30, an Internet gateway 
32 and a Vertical Blanking Interval (VBI)-to^MPEG transcoder 34. Figure 2 further shows a broadcast domain name 



40 
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server (DNS) 36. a digital addressable controller (DAC) 38, a switch such as an Ethernet switch 40. an IP encaspsulator 
42, a controller 44, a modular processing system (MPS) 46, a satellite dish 48. an up-converter 50, and cable.plant 52. 
[0016] Terminal 24 may comprise any one of an advanced set-top box (ASTB), a set-tOp terminal, a consumer terminal 
such as a digital consumer terminal (DCT), a cable television entertainment terminal such as a digital consumer terminal 
5 (DCT). a digital television, or a host with point of deployment (POD) capability including a suitably configured personal 
computer (PC). 

[00171 Terminal 24. according to the Invention, may provide a platform for running third-party applications, which 
may be configured to request connections to IP data sources associated with a cunrently tuned service; or, available 
. on a completely different Transport Stream (TS). Terminal 24 is configured to locate the data stream (i.e., a particular 

10 packet identification -PID) carrying the requested IP data using an inventive descriptor, and thereafter reassemble the 
IP datagrams fragments taken from the MPEG transport packets. . The IP data will then be extracted and passed to IP 
layer software also running on terminal 24 for further processing. Terminal 24 may comprise otherwise conventional 
components known in the art, modified according to the Invention described herein. Network server 30, Internet gateway 
32, and transcoder 34 may comprise conventional components known to those of ordinary skill In the art. 

IS [0018] Digital Addressable Controller (DAC) 38 allows local control and authorization for functionality to already 
deployed terminals 24, among other functions. DAC 38 may comprise commercially available equipment, such as 
model DAC 6000 Digital Addressable Controller, available from General Instrument Corporation. Horsham Pennsyl- 
vania. USA, 

[0019] IP encapsulator 42 (and its associated controller 44) may also comprise commercially available components. 

20 known to those of ordinary skill in the art. 

[0020] MPS 46 is configured as a processing platform for Incoming digital data streams. MPS 46 may perform such 
digital processing functions as encryption/decryption, stream multiplexing, rate conversion, .hiessage insertion and 
extraction, and can be configured with a variety of input and output options, such as DS3 I/O, 64/256 QAM (output) at 
IF carrying an MPEG-2 Transport Stream (TS). and the like. MPS 46 may comprise commercially available equipment. 

25 such as model MPS-Modular Processing System available from General Instrument Corporation. Horsham, Pennsyl- 
vania. USA. 

[0021] Up converter 50 Is configured to (i) receive a 64 or 256 QAM signal at IF from MPS 46 and (ii) up-convert the 
IF signal to RF for distribution on a selected physical channel on plant 52, as known. Up-converter 50 may comprise 
commercially available component, such as model C6U from General Instrument Corporation, Horsham. Pennsylvania, 
30 USA. 

[0022] The present invention involves generating a descriptor, which is transmitted with a Program Map Table (PMT) 
on the cable plant, destined to be received and processed by one or more of terminals 24. Third party application 
developers may transmit one-way IP datagrams (e.g.. IP multicast containing ATVEF data) to their applications running 
within terminal 24. Without the above-described descriptor, the terminal 24 must engage in substantial processing to 
35 parse data streams looking for the desired IP data, or worse, must reassemble the fragmented IP datagrams In order 
to recover and process the destination address. The descriptor, in accordance with the present Invention, facilitates 
earlier decision making and faster processing in terminal 24. 

[0023] With continued reference to Figure 2, IP datagrams from various IP data sources are provided to IP encap- 
sulator 42 over a network, such as, for example, an Internet network. These IP data sources may include a local network 

40 server 30. transcoder 34 having one or more analog broadcasts as inputs that provide IP data contained in the vertical 
blanking interval, or gateway 32 via its connections to the Internet. These sources in-turn transmit the IP datagrams 
via switch 40 to IP encapsulator 42. While shown as Ethemet. the IP-data source to encapsulator 42 path may comprise 
other transmission technologies. Each IP encapsulator 42 extracts IP data from the Ethernet frames and encapsulates 
them, in one embodiment, within DVB-MPE datagrams sections 14^ 14^, as shown in exemplary fashion in Figure 

45 1 . Table 1 , below, shows an exemplary syntax for the DVB-MPE sections. The DVB-MPE standard is a public standard, 
and will be described in connection with Table 1 only insofar as relevant to the present invention. The IP encapsulator 
42 thereafter segments the DVB MPE datagrams sections into MPEG transport packets 16j and transmits them to 
modular processing system 46. MPS 46 receives the MPEG transport packets from IP encapsulator 42 and may mul- 
tiplex the received PID streams with MPEG video/audio services received from a satellite down link 48 or video server. 

50 or the like. 

[0024] In an alternate embodiment, network server 30 may perform the DVB-MPE encapsulation of the IP datagrams 
and provide the result directly to MPS 46 over a DVB System Parallel Interface (SPl) or Asynchronous Serial Interface 
(ASI). 

55 
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Table 1. DVB-MPE Datagram Section 



10 



15 



20 



25 



Syntax 

daiagram_section() { 
table Jd 

scction_5yntax_indicator 

private_indicator 

reserved 

section_length 

device]d_6 

deviceld_5 

reserved 

pay]oad_S€ramblmg_control 
address^scrambling^control 
LLC^SNAP^nag 
curr cnt^ncx l_indicator 
section^number 
lasr_section_nurober 
devlceld_4 
deviceld_3 
deviceld_2 
deviceld 1 

iftLLC_SNAP_flag = '!'){ 
LLC_SNAP() 

} 

else { 

for(i-0;j<Nl u'^^) { 



No. of bits 


Format 


8 


'0x3E' uimsbf 


1 

* 


\V 


1 




2 




12 


Uimsbf 


8 


Uimsbf 


8 


Uimsbf 


2 


'ir 


2 


•00' 


2 


•00* 


1 


*0' 


1 




8 


Uimsbf 


8 


Uimsbf 


8 


Uimsbf 


8 


Uimsbf 


8 


Uimsbf 


8 


Uimsbf 



30 



IF_datagram_bylc 


8 


Bslbf 


\f{ section number = Iast_scciion_number) { 
for(j=Ou<N2J++) { 
stuffing^byie 

} 


8 


Bslbf 


} 

if(seciion_syntax_indicaior —'0*) { 
checksum 
} 

else { 

CRC^32 

) 

} 


32 


Uimsbf 




ipchof 



[0025] The table_id parameter Is an 8-bit field which is set to "0x3E", indicating DSM-CC sections with private data 
in accordance with ISO/IEC 13818-6 [2]. The deviceld_1 through deviceid_6 parameters define a MAC__address_[1.. 
6], i.e.. this is 48-bit field that contains the MAC address of the destination. The MAC address is thus fragmented into 
6 fields of 8-bits each, labeled deviceld^l to deviceld_6. The devlceld_1 field preferably contains the most significant 
byte of the MAC address, while deviceld_6 contains the least significant byte. RFC 1112 specifies the mapping from 
Multicast IP addresses to Ethernet MAC addresses. The MAC address fields, in a preferred embodiment, are encoded 
in accordance with this mapping. The mapping is straight-forward and is as follows. The IP multicast address will be 
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mapped Into the corresponding hardware multicast address by placing the low-order 23 bits of the IP multicast address 
Into the lower order 23 bits of the multicast MAC address 01 .00.5E.0O.00.00 (base 16). 

[00261 In addition, the section_number parameter is an 8-blt field. If the IP datagrar^ is carried in multiple sections, 
then this field indicates the position of the section within the fragmentation process. Otherwise it will be zero. It should 

5 be appreciated that, in one embodiment, the IP datagram fragments must be delivered to the data link layer such that 
they are no larger than the Maximum Transmission Unit (MTU) size of 1008 bytes. By doing this there is no need to 
further segment the IP datagram fragments across DVB-MPE datagram sections. The last_section_number parameter 
is an 8-bit field that indicates the numbei- of the last section that is used to carry the datagram, i.e.. the number of the 
• last section of the fragmentation process. 

10 [00271 With continued reference to Figure 2, a description of the operation of the invention on the network side (as 
opposed to the terminal side) will be set forth. The DAC 38 sends commands to MPS 46 (e.g.. a load_mps commands) 
to control service re-multlplexing. Program Specific Information (PSI) message extraction and insertion, and service 
encryption. Additionaily, DAC 38 sends to MPS 46 other commands (e.g., Include Component commands) that identify 
input elementary PID streams that are to be included within a defined output service. This capability of MPS 46 will be 

15 used to map the appropriate PID streams carrying IP data into a particular service multiplex. In accordance with the 
present invention, the commands sent by DAC 38 (e.g.. Include Component) will also be used to provide to MPS 46 
(i) a stream^type and (ii) the above-described descriptor associated with the input PID stream carrying IP datagrams 
destined for terminals 24. The MPS can thus send a PMT including the stream-type and address descriptor out on the 
MPEG-2 Transport Stream. The processing that occurs in temiinal 24. using the inventive descriptor, will be described 

20 in detail below. 

[0028] Figure 3 illustrates protocol stacks an IP data source, for example, network server 30. IP encapsulator 42. 
MPS 46 and terminal 24 for one-way IP datagram broadcasts. Shown in Figure 3, IP encapsulator 42 presents a 
standard network interface to a third-party network server 30. Encapsulator 42. as described above, performs the 
encapsulation of received IP datagrams into, for example, DVB-MPE datagram sections, such as sections 14^ 14„, 

25 shown in Figure 1 . The encapsulated IP datagrams are then segmented into MPEG transport packets which are passed 
to MPS 46 for distribution to terminals 24 by way of. for example. 64/256 QAM via upconverter 50. 
[0029] Figure 4 shows a Program Map Table (PMT) 54 in accordance with the present invention. PMT 54, as known 
to those of ordinary skill in the art, may be transmitted on a program map data stream of an MPEG-2 transport stream. 
The optimization that is obtained according to the invention is achieved by combining the appropriate information of 

30 both the IP and MPEG protocols in order to facilitate earlier decision making and faster processing in terminal 24. This 
optimization is accomplished by defining a new data structure, referred to in MPEG nomenclature as a descriptor It is 
known to those of ordinary skill in the art that in MPEG-2. the transport multiplex may include several program streams 
(services) which are indicated in a Program Association Table (PAT). Each program stream (service) may comprise 
one or more video, audio, and data Packetized Elementary Streams (PES). The elementary streams that make up a 

35 program are pointed to by the Program Map Table (PMT). For example, as shown in Figure 4. PMT 54 includes a PGR 
(i.e.. timing) stream 56i, a first video stream 662. a first audio stream 563. a second audio stream 664. and a data 
stream 56k. The PMT 54 points to each elementary stream by providing in the table a respective Packet Identification 
(PID) number where the particular stream in the Transport Stream as a whole may be found. For example, the video 
stream for program number 1 is indicated in PMT 54 as being carried on PID=54. In addition, each entry in PMT 54 

40 has a corresponding elementary stream-type descriptor, such as type descriptor 58 for data stream entry 56^. 

[0030] As further illustrated, for an MPEG service (program) that carries IP datagrams within two or more elementary 
PID streams of stream Jype = OxOD (DSM-CC sections), in accordance with the invention, each such data stream 
further includes an address descriptor 60 PMT 54. That is, when a data component (i.e.. an elementary stream) assor 
dated within a given audiovisual service is comprised of IP datagrams, address descriptor 60 is included that enables 

45 terminal 24 to determine when it needs to parse and reconstruct (i.e., reassemble the IP datagrams from the DSM-CC 
sections, for example) and when it should ignore the incoming data. In particular, address descriptor 60 will be proc- 
essed by terminal 24 to determine if the component PID stream can*ies multicast IP data. 

[00311 In addition, descriptor 60 will carry one or more multicast Media Access Control (MAC) addresses of the 
DVB-MPE datagram sections that are being carried within a particular component PID stream. Because MPEG mes- 

50 sages are limited to 1024 bytes in length, the maximum number of MAC addresses will be limited to approximately 
150 entries depending on the number of other descriptors carried in the PMT, as well as the number of component 
PIDs being identified. In constructed embodiments, a maximum of 150 entries should leave sufficient room to carry 
the commonly defined PMT descriptors (e.g.. language, conditional access, etc.) as well as the mandatory PMT mes- 
sage fields. In an alternative embodiment, if there are more than 150 MAC addresses being carried on a particular PID 

55 stream, or if there are many data PID streams that each carry large numbers of different IP datagram streams, then a 
range of MAC addresses can be specified. Descriptor 60 enables terminal 24 to quickly and efficiently identify the data 
PID streams carrying requested IP data, without having to extract and reassemble DVB-MPE messages in order to 
filter multicast MAC addresses. An exemplary syntax for descriptor 60 is shown below in Table 2, along with the related 
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definitions. 



10 



15 



20 



25 



Table 2. Address Descriptor 



Syntax 

MAC_Address_List _descriptor() { 
descriptor_tag 
descriptorjength 
(lata_streain_content 



if (daU_strcam_content — inc_mac_addr_mcluded){ 
nunn_of_mac_addrcsscs 
for (i^ofi < nuin_of_inac_addresses; i++){ 
multicast_niac address 

} 

else if (data^strcam^contem = nic_mac_addr_rangc_included){ 
hlghest.itiac_addrc$s 
iowcst_inac_address 



No. of 
bits 



8 



48 



else { 



> 



for (i-0; i < descriptor Jenglh -1; •++){ 
Reserved «lata_byte 
} 



8 



Moemonic 



uimsbf 
uixnsbf 
uimsbf 

{mc^mac^addr^includcd, 
Tnc_mac_addr_rangc_inclu 

ded, reserved 1...N) 

uimsbf 

uimsbf 



uimsbf 
uimsbf 



uimsbf 



30 [0032] The descriptor tag parameter is an 8-bit unsigned integer quantity that defines the particular descriptor date 
structure. The descriptoMength parameter is an 8-bit unsigned integer number that defines the length of the descriptor 
immediately following the field: 

The length parameter includes everything in the descriptor structure except the descriptor tag P^I^-^f 
length byte itself. The data_stream_content parameter is an 8-bit enumerated type field that identifies the contents 
of the descriptor. The multicast_mac_addrjncluded descriptor includes a set of destination multicast MAC ad- 
dresses. The multicast mac_addr_rangejncluded descriptor includes a range of destination multicast MAC ad- 
dresses where the range is specified by the highest_mac_address and lowest mac address fields. The 
num of mac addresses is an 8 bit unsigned integer that indicates the number of multicast MAC addresses con- 
40 teine'd v;;ithin Fhis descriptor. The multlcast_mac_address parameter is a 48 bit multicast MAC group address. The 

highest mac address is a 48 bit multicast group MAC address that is the largest "^^^'f ^''^ ''^^^"f "''J/l^^ 
lowest mac address is a 48 bit multicast group MAC address that is the smallest earned by descriptor. Other 
variations are possible, depending on the particulars of any cable and/or satellite television system. 

45 [00331 Figure 5 shows a flowchart illustrating how an application executing on terminal 24 can establish a connection 
to receive IP date. Figure 5 further shows how terminal 24 . particularly a decoder portion thereof, will locate and extract 
multicast IP datagrams that have been requested by an application by specifying the associated multicast MAC address 
The application connection process begins in step 62. ^ . ^ f,„^ 

[00341 In step 64, applications executing on terminal 24 open "socket" connections to obtain IP date, typically from 

50 an in-band IP date source. However, in an alternate embodiment, terminal 24 Includes a cable-modem t"ner and 
associated circuitry and software, allowing the applications executing on terminal 24 to obtain IP data from a DOCSIS- 
compliant IP date source. For example, commercially available terminals, such as model DCT 5000 avaHable from 
General Instmment Corporation. Horsham. Pennsylvania. USA, includes such a ^3'>'«:'"°5®""^^^P^'''';^;,!^_^^^^ 
network interface will provide a rec»^ronj datagram service for connections to both in-band IP date and DOCSIS data 

55 sources. In addition, this interface will support a sendto datagram service and two-way socket stream date seivice for 
connections via the DOCSIS channel only. The method proceeds to step 66. 

[00351 In step 66. the processing logic determines what kind or type or connection is being requested by the appli- 
cation When the application opens a socket stream connection {i.e.. TCP connection) or wante to send UDP datagrams 
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upstream then terminal 24 will use means for upstream transmission, for example, a DOCSIS port, as shown In step 
68 When an application opens a socket connection and wants to "listen-only" for a particular destination IP address 
and UDP port terminal 24 will listen on the cun-ently tuned in-band service, and optionally, the DOCSIS port (if terminal 
24 is so equipped) for the data. It bears emphasizing that the muRicast IP address and UDP port may be "Well Known 
to the application {i.e.. published or otherwise available from the assigned number authority) or may be delivered to 
the application running on the terminal 24 through other mechanisms {e.g.. an ATVEF Announcement). 
[00361 In step 70 the multicast IP address is mapped into a multicast MAC address. This mapping may be accom- 
plished by mapping the lower 23 bits of the multicast IP address into the lower 23 bits of the multicast MAC address 
01 00 5E 00 00 00. This mapping approach is set forth in RFC 1112 hereby incorporated by reference in its entirety. 
The process then proceeds to decision step 72. The processing that begins at this point, designated "A" (i.e.. imnrie- 
diately before decision step 72). is the begin processing point for terminal 24 whenever a "new" Program Map Table 

(PMT) is received. \. 
[0037] In step 72. terminal 24 determines whether the received PMT contains a PID data stream of stream-type 
OxOD For example, as shown in Figure 4. the packetized elementary stream Identified as 56^ has a stream _type of 
OxOd' which indicates that the data contained in that data stream is IP data. If the answer is "NO", then the method 
branches to step 74. wherein the decoder portion of terminal 24 notifies the application running on terminal 24 that the 
reauested IP data could not be found.The method proceeds to step 76. wherein the decoder portion waits (e g- loops) 
until a new PMT is received. At such time as a new PMT is received by terrninal 24, the control is transferred to point A . 
[00381 However, if the answer to decision step 72 is "YES", then the method proceeds to step 78. 
[00391 In step 78, the decoder portion determines whether the PMT received by terminal 24 (e.g.. PMT 54 shown in 
Figure 4) contains address descriptor 60 in accordance with the present invention. If the answer is NO . then the 
method proceeds to steps 80 and 82. wherein the conventional approach for processing received data is followed. 
That is the DVB-MPE datagram sections are extracted. IP datagram fragments are examined. In particular, the decoder 
will examine the tablejd field of messages being carried within the first data PID component of streamjype OxOD. \ 
the table id is not equal to 0x3E (DVB-MPE datagram section), the decoder portion will ignore the message and will 
look at th"e next message In the PID stream. As described in the Background, this approach Is not optimal, and may 
impose unnecessary resource burdens (e.g.. processing and memory requirements) on terminal 24. 
[00401 If the answer to step 78 is "YES", however, the method proceeds to step 84. In step 84. the decoder portion 
of terminal 24 extracts and processes all the MAC addresses listed in the descriptor 60 contained in PMT 54. As shown 
In Table 2. descriptor 60 may particularty identify the multicast MAC addresses, or may indicate a range of multicast 
MAC addresses. The method then proceeds to step 86. ^ .„ ^ . u., ,k= 

[0041] in step 86. the decoder portion of terminal 24 determines whether the requested IP data as indicated by the 
mapped multicast MAC address (from step 70) Is listed In descriptor 60. or in the range «P^«='«f ^ 
t^e answer is "NO", then the method proceeds to step 88 wherein the application running on terminal 24 is notified 
St mJTp data cannot presently be found, but that a search will continue. The decoder portion of termmal 24 wiHa so 
process all other address descriptors associated with other data PID streams of stream_type OxOD even if the requested 
multicast MAC address has been found. This is because there may be identical multicast MAC addresses carried on 
other stream components. This scenario results because of the mapping approach "^ed for mapping multicast IP 
addresses to multicast MAC addresses, which is not guaranteed to produce unique multicast MAC addresses^Mult.cast 
IP addresses have 28 significant bits (the first four are fixed identifying a Class D address). As described above only 
he lowerTs bits are mapped into the lower 23 bit poslttons of the multicast MAC address 01 .00.5E.OO.oa00. Thus, a 
is possible for different multicast IP addresses to map into the same multicast MAC address, at least under the approach 
set forth in RFC 1112 used In a constructed embodiment. Preferably. IP data sources (for example, as shown In Figure 
2) take this detail into account in selecting a multicast address or range of addresses so as to maintain a unique 
multicast MAC address on any particular network. 
[00421 The method proceeds to step 90. 

(0043 In step 90. the decoder of terminal 24 selects a stream or multiple streams and starts message extractjon. 
Once the decoder has begun extracting the DVB-MPE datagram sections being carried within one or more data PID 
streams it will insure that the tablejd field of the messages is "OxSE". which Indicates that the message is a DVB-MPE 
datagram section. This step is shown as decision step 92 in Figure 5. If the answer is "NO", then the method branches 
to step 94. wherein the next DSM-CC message is extracted for processing. If . however, the answer to step 92 is "YES . 
then the method branches to step 96. mm.^^^ 
[00441 In step 96. (e.g.. the tablejd = "0x3E"), the decoder of terminal 24 compares the 48 bit multicast MAC address, 
as carried within the datagram section (see Figure 1). with the requested multicast MAC address (formed step 70^ 
The filtering and comparison steps as shown as steps 96. 98 in Figure 5. If the answer is "YES , then the DVB-MPE 
datagram section is confirmed as carrying a segment of the IP datagram requested by the application. Control passes 
to step 100 wherein the decoder of terminal 24 wilt extract the IP datagram segments from the DVB-MPE datagram 
sections The decoder of terminal 24 will thereafter pass the extracted IP datagram fragment to an IP layer software 
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portion, also running on terminal 24; as shown in step 102. The method then proceeds to step 94. wherein the next 
message is extracted for further processing. 

[0045] If. however, the answer to step 98 is "NO", then, one further check must still be made. The data link layer of 
processing of terminal 24 preferably behiaves In a manner similar to a standard network interface. Therefore, the de- 
5 coder of terminal 24 must check to determine whether the MAC address is a so-called broadcast MAC address (i.e.. 
all ones). If the decoder of terminal 24 determines that a MAC broadcast address has been received, as shown in step 
104. then it will extract the IP datagram fragment from the DVB-MPE datagram section, and pass it to the IP layer for 
further processing, as described above in steps 100, 102. 

10 EXAMPLE 

[0046] The present invention Is adapted for facilitating the delivery of content in a content data stream (e.g.. IP 
datagrams) to a terminal. In a particular example, the content complies with an Advanced Television Enhancement 
Forum (ATVEF) specification for advanced television programming. The ATVEF standard enables the association of 

15 HTML pages with an audiovisual service, which are adapted for broadcast and reception by a compliant receiver, such 
as terminal 24. The content is delivered via IP protocol. The ATVEF specification, referred to in the Background, does 
not specify the delivery or the binding mechanism under the IP layer, although, as also discussed in the Background, 
certain standards have beep proposed that provide the mapping (adaptation) of the IP protocol onto an MPEG transport 
layer (shown in Figure 1). For example, the ATVEF Transport Type B Broadcast data is delivered to an application 

20 (executing on terminal 24), as three different components: Announcements. Triggers, and Resources. Announcements 
may be delivered to an application on a "Well Known" Multicast IP address and UDP port. Each Announcement points 
to a Trigger and Resource that are available to the application on the specified Multicast IP addresses and UDP ports. 
. In a common arrangement, the Announcements, Triggers, and Resources are included as part of the same data stream 
component This data stream component will be associated with a particular MPEG program by identifying that com- 

25 ponent within the PMT. Data stream components of stream_type = "OxOD" (i.e.. DSM_CC_section), for example, may 
contain this ATVEF IP data. In accordance with the present invention, the PMT is configured to carry an address 
descriptor 60. which will be used by terminal 24 in determining whether the data stream component carries IP data. 
Descriptor 60 includes the destination multicast address of the IP data within the stream. The decoder portion of terminal 
24 can then use this information to quickly determine if the data stream carries IP data destined for the currently tuned 

30 MPEG program, without having to continuously extract the IP data and pass it to the higher layers for filtering. 

[0047] The basic application of the present invention for enabling enhanced audiovisual services via ATVEF is as 
follows. First, the terminal 24 is tuned to an MPEG service containing IP data corresponding to at ATVEF content. An 
application mnning on terminal 24 then requests a connection to a Well Known multicast IP address and UDP port 
carrying ATVEF Announcements. The terminal 24, according to the MPEG-2 standard, locates and extracts a Program 

35 Association Table (PAT) in order to find the PMT associated with the audiovisual service. The terminal 24 then extracts 
the PMT in order to identify the various service components (audio, video, data) associated with the tuned service. 
When terminal 24 observes data component PID streams of stream Jype OxOD (DSM- CO sections), then it. according 
to the invention, examines the inventive address descriptors (e.g., address descriptor 60) associated with such content 
data stream. From descriptor 60, the terminal 24 determines that the PID stream carries IP data, and further the mul- 

40 ticast MAC addresses associated with such content data stream. 

[0048] The decoder of terminal 24 then parses through the list of MAC addresses in descriptor 60 (or multiple de- 
scriptors 60 if multiple component data streams of type OxOD are present), looking for the multicast MAC address 
requested by the application. The list of multicast, destination MAC addresses may be cached, locally, for later use. 
[0049] If the requested multicast MAC address (e.g., as mapped in step 70. Figure 5) is contained in the list of 

45 multicast MAC addresses In descriptor 60, then terminal 24 assigns a PID filter to extract DVB-MPE datagram sections 
from the respective data PID stream(s). Otherwise, terminal 24 loops, waiting for a new PMT version. 
[0050] Terminal 24 then begins extracting DVB-MPE datagram sections. Terminal 24 compares the MAC address 
fields in the DVB-MPE datagram section (i.e.. the devlcejd parameters Table 1) to the requested multicast MAC 
address. If there is a match, the terminal 24 extracts one or more IP datagram fragments from the corresponding 

50 DVB-MPE datagram sections payload. 

[0051] Terminal 24 then passes the IP datagram fragment, carrying a portion of the ATVEF Announcement message, 
to IP layer software for reassembly into a complete IP datagram and further IP layer processing. 
[0052] If enabled by subscriber 22, the application may thereafter request a connection to a Trigger and Resource 
IP address(es) and UDP ports, as provided for in the captured Announcement. 

55 [0053] In one embodiment, the application determines what ATVEF Trigger and Resources to request based on, for 
example only, a language preference. The application further requests (internal to the operating system of terminal 24) 
sufficient memory/bandwidth to accept the largest resource/fastest download. According to the ATVEF standard (see 
the Background), there are provisions for different levels of resources which use varying levels of memory and/or 
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require greater bandwidth. 

[0054] Terminal 24 then examines cached multicast MAC addresses from previously examined PMT descriptors 60 
associated with data PID streams. The terminal 24 determines which stream carries the requested IP data and extracts 
IP data fragments from DVB-MPE datagrams sections. The terminal 24 then passes the captured IP datagram frag- 

5 ments to the I P layer software for re-assembly into a complete IP datagram and for further IP processing. The application 
caches the captured Resource data and processes a Trigger in a like manner when it arrives at tenninal 24. Through 
the foregoing, a subscriber efficiently gains access to an audiovisual service, enhanced by ATVEF data. 
[0055] According to the invention, a Program Map Table (PMT) used in a MPEG digital network is configured to carry 
a new message-an address descriptor. The address descriptor facilitates the delivery of IP data to a subscriber's 

10 terminal by providing information (i.e.. a multicast MAC address) useful to the terminal in efficiently locating the com- 
ponent PID data stream the carries the content (IP data). 

[0056] The foregoing is exemplary and not limiting in nature, modifications and variations are possible without de- 
parting from the scope of the Invention, which are limited only by the appended claims. It should be understood that 
variations are possible. For example, although the above describes a scenario where the in-band IP data is directly 

15 associated with a particular MPEG program (i.e.. audiovisual service), It should be understood that alternate embod- 
iments provide a system where an application on terminal 24 is able to locate services canrying IP data either within 
the currently tuned MPEG transport stream (as described above) or an entirely different MPEG transport stream or 
streams. The present invention, in addition, is generally applicable to facilitating delivery of IP data, one example of 
which is the carriage of ATVEF IP data. However, other uses include, but are not limited to. facilitating delivery of IP 

20 . data from an Internet website, or. as another example, the delivery of code objects to terminal 24 (e.g., operating 
systems, applications, etc.). 



25 



Claims 

1. A method for facilitating delivery of content in a content data stream to a terminal (24), said method comprising 
the steps of: 

generating a descriptor (60) for the content data stream, said descriptor (60) including at least one destination 
30 address, said at least one destination address comprising at least one multicast Media Access Control address; 

and 

transmitting the descriptor to the terminal (24) in a Program Map Table (54); 

locating the content data stream using the destination address in the descriptor (60) at said terminal (24). 
35 2. The method of claim 1 further including the step of: 

extracting a message corresponding to the identified content from the content data stream. 

3. The method of claim 1 wherein the data service is transmitted to the terminal in a Moving Pictures Expert Group- 
40 2 (MPEG-2) transport stream. 

4. The method of claim 3 wherein the content complies with an Advanced Television Enhancement Forum (ATVEF) 
specification for advanced television programming. 

45 5. The method of claim 4 wherein the ATVEF content is carried using the User Datagram Protocol (UDP) and Internet 
Protocol (IP), said method further comprising the steps of: 

encapsulating IP datagrams in a form capable of being carried in an MPEG-2 transport stream; and 
transmitting the encapsulated IP datagrams to the terminal (24) in the transport stream. 

50 

6. The method of claim 5 wherein the transmitting step comprises the substep of: 

multicasting the encapsulated datagrams to plurality of terminals including said terminal (24). 

55 7. The method of claim 5 wherein said form corresponds to a Digital Video Broadcasting/Multi-Protoco! Encapsulatiori 
(DVB-MPE) specification for datagram sections. 

8. The method of claim 5 wherein said form corresponds to an Advanced Television Systems Committee (ATSC) 
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specification for addressable concerns. 

9. The method of claim 6 further including the steps of: ' ' 

executing an application on the terminal (24) configured to use the content; 

requesting a connection to a rnulticast IP address where the content may be located; and 

mapping the multicast IP address to a con-espondlng multicast Media Access Control address. 

10. The method of claim 9 wherein said step of locating the content data stream includes the substeps of: 

extracting said at least one multicast Media Access Control address included in the descriptor from the Program 
Map Table (54); and 

determining whether the mapped multicast Media Access Control address is included in the extracted at least 
one multicast Media Access Control address. 

11. The method of claim 10 further including the step of: 

extracting a message conresponding to the ATVEF content when the mapped multicast Media Access Control 
address is included in the extracted at least one multicast Media Access Control address. 

12. The method of claim 11 further including the step of: 

providing, via the application, enhanced audiovisual service in accordance with the extracted message. 

13. The method of claim 1. wherein the data service is an audiovisual service, and wherein the content data stream 
and Program Map Table (54) is associated with the audiovisual service. 

14. The method of any preceding claim wherein said method facilitates delivery of said content data stream to said 
terminal (24) through a Moving Pictures Expert Group (MPEG) transport stream for enhancing a data service 
carried by said MPEG transport stream, said method including the.step of: 

recovering a message from the content data stream that corresponds to the content using the destination 
address included in the descriptor (60). 

15. The method of claim 14 wherein the message is carried in the same service stream of said MPEG transport stream 
as the data service 

16. The method of claim 15 wherein the content comprises Advanced Television Enhancement Forum (ATVEF) com- 
pliant content. 

17. An apparatus for facilitating delivery of a content data stream including content through a Motion Pictures Expert 
Group (MPEG) transport stream to a terminal (24) for enhancing an audiovisual service, said apparatus comprising: 

a memory configured to store a multicast IP address associated with said content data stream; and 
a processor configured to generate an address descriptor (60) destined for inclusion in a Program Map Table 
(54), said descriptor (60) including at least one destination address generated in accordance with said multicast 
IP address; wherein 

said at least one destination address comprises at least one multicast Media Access Control destination ad- 
dress. 

18. A terminal comprising: 

an application configured to request a connection to a multicast IP address for receiving content configured 
to enhance a data service; 

means for examining a Program Map Table (54) associated with said audiovisual service for the presence of 
an address descriptor (60). said address descriptor (60) including a multicast Media Access Control address; 
and 

means for recovering a message corresponding to said content when using said multicast Media Access 
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Control address and providing said message to said application, 
Patentanspriiche 

1. Ein Verfahren zum Erieichtern der Lieferung von Inhalt in einem Inhaltsdatenstrom an ein Terminal (24), wobei 
das Verfahren folgende Schritte beinhaltet: 

Erzeugen eines Deskriptors (60) fur den Inhaltsdatenstrom, wobei der Deskriptor (60) mindestens elne Ziel- 
adresse umfasst. wobei die mindestens eine Zieladresse mindestens eine Multicast-Medienzugriffssteue- 
rungsadresse beinhaltet; und 

Obertragen des Deskriptors auf das Terminal (24) In einer PMT (54) (Program Map Table); 

Lokalisieren des Inhaltsdatenstroms unter Verwendung der Zieladresse in dem Deskriptor (60) an dem Ter- 
minal (24). 

2. Verfahren gemaR Anspmch 1 , das ferner folgenden Schritt umfasst: 

Extrahieren einer Meldung, die dem identlfizierten Inhalt aus dem Inhaltsdatenstrom entspricht. 

3. Verfahren gemali Anspruch 1 . wobei der Datendienst in einem MPEGt2 Transportstrom (Moving Pictures Expert 
Group-2 Transportstrom) auf das Terminal Obertragen wird. 

4. Verfahren gemaft Anspruch 3. wobei der Inhalt mit der ATVEF-Spezifikation (Advanced Television Enhancement 
Forum) zur verbesserten Fernseh-Programmgestaltung konform ist. 

5. Verfahren gemSfi Anspruch 4. wobei der ATVEF-lnhalt unter Verwendung des UDP-Protokolls (User Datagram 
Protocol) und des IP-Protokolls (Internet Protocol) getragen wird. wobei das Verfahren ferner folgende Schritte 
beinhaltet: 

Verkapsein von IP-Datagrammen in eine Form, die in einem MPEG-2-Transportstrom getragen werden kann; 
und 

Obertragen der verkapselten IP-Datagramme auf das Terminal (24) im Transportstrom. 

6. Verfahren gemafi Anspruch 5, wobei der Obertragungsschritt folgenden Unterschritt beinhaltet: 

Sammelsenden der verkapselten. Datagramme an eine Vielzahl von Terminals, einschlieftlich des Terminals 
(24). 

7. Verfahren gemSft Anspruch 5, wobei die Form einer DVB-MPE-Spezifikation (Digital Video Broadcasting/Multi- 
Protocol Encapsulation) fOr Datagrammat)schnitte entspricht. 

8. Verfahren gemafi Anspruch 5. wobei die Form einer ATSC-Spezifikation (Advanced Television Systems Commit- 
tee) fur adressierbare Angelegenheiten entspricht. 

9. Verfahren gemSB Anspruch 6, das ferner folgende Schritte umfasst: 

AusfOhren einer Anwendung auf dem Terminal (24), das zur Venwendung des Inhalts konfiguriert ist; 
Anfordern einer Verbindung zu einer Multicast-lP-Adresse. an der sich der Inhalt befmden kann; und 
Abbilden der Multicast-IP-Adresse auf einer entsprechenden Multicast-Medienzugriffssteuerungsadresse. 

10. Verfahren gemSft Anspruch 9. wobei der Schritt des Lokalisierens des Inhaltsdatenstroms folgende Unterschritte 
umfasst: 
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Extrahieren der mindestens einen Multicast-Medienzugriffssteuerungsadresse. die in dem Deskriptor aus der 
PMT (54) (Program Map Table) eingeschlossen ist; und 

Bestimmen. ob die abgebildete IVIulticast-Medlenzugriffssteuerungsadresse in der mindestens einen extra- 
5 hierten Multlcast-Medienzugrlffssteuerungsadresse eingeschlossen ist. 

11. Verfahren gemSli Anspruch 10. das ferner folgenden Schritt umfasst: 

, Extrahieren einer Meldung. die dem ATVEF-lnhalt entspricht, wenn die abgebildete Multicast-Medienzugrlffs- 

10 steuerungsadresse in der mindestens einen extrahierten Multlcast-Medienzugriffssteuerungsadresse einge- 

schlossen ist. 

12. Verfahren gemSR Anspruch 11 . das ferner folgenden Schritt umfasst: 

15 Bereltstellen eines verbesserten audiovisuellen Dienstes In Oberelnstimmung mit der extrahierten Meldung 

uber die Anwendung. 

1 3. Verfahren gemafi Anspruch 1 . wobei der Datendienst ein audiovisueller Dienst ist und wobei der Inhaltsdatenstrom 
und die PMT (54) (Program Map Table) mit dem audiovisuellen Dienst verbunden sind. 

20 . 

14. Verfahren gemaii einem der vorhergehenden AnsprOche. wobei das Verfahren die Lleferung des Inhaltsdaten- 
stroms an das Terminal (24) durch einen MPEG-Transportstrom (Moving Pictures Expert Group-Transportstrom) 
zum Verbessern eines Datendienstes, der durch diesen MPEG-Transportstrom getragen wird, erieichtert. wobei 
das Verfahren folgenden Schritt umfasst: 

25 

Wiedergewinnen einer Meldung aus dem Inhaltsdatenstrom, der dem Inhalt. der die in dem Deskriptor (60) 
eingeschlossene Zieladresse verwendet, entspricht. 

15. Verfahren gemafl Anspruch 14, wobei die Meldung In demselben DIenststrom des MPEG-Transportstroms wie 
30 der Datendienst getragen wird. 

16. Verfahren gemafl Anspruch 15. wobei der Inhalt ATVEF (Advanced Television Enhancement Forum) konformen 
Inhalt beinhaltet. 

35 17, Eine Vorrichtung zum Ehelchtern der Lleferung eines Inhaltsdatenstroms. einschlteflltch Inhalts. durch einen 
MPEG-Transportstrom (Motion Pictures Expert Group Transportstrom) an ein-Termlnal (24) zum Verbessern eines 
audiovisuellen Dienstes, wobei die Vorrichtung Foigendes belnhaftet: 

einen Speicher, der konfiguriert ist. um eine mit dem inhaltsdatenstrom verbundene Multicast- 1 P-Adresse ab- 
40 zuspeichern; und 

elhen Prozessor. der konfiguriert Ist, um einen Adressdeskrlptor (60) zu erzeugen. welcher zum Einschluss 
in einer PMT (54) (Program Map Table) vorgesehen ist, wobei der Deskriptor (60) mindestens eine in Ober- 
einstimmung mit der Multicast-I P-Adresse erzeugte Zieladresse umfasst; wobei 

45 • 

die mindestens eine Zieladresse mindestens eine Multlcast-Medienzugriffssteuerungs-Zieladresse beinhaltet. 

18. Ein Terminal, das Foigendes beinhaltet: 

50 eine Anwendung, die konfiguriert ist. um eine Verbindung mit einer Multicast-I P-Adresse zum Empfang von 

Inhalt. der konfiguriert ist, um einen Datendienst zu verbessern, anzufordern; 

ein MIttel zur Oberprufung einer PMT (54) (Program Map Table), die mit dem audiovisuellen Dienst fur die 
Bestimmung der Anwesenheit eines Adressdeskriptors (60) verbunden ist. wobei der Adressdeskrlptor (60) 
55 eine Multicast-Medienzugriffssteuerungsadresse umfasst; und 

ein MIttel zur Wiedergewinnung einer Meldung. die dem Inhalt entspricht, wenn diese Multicast-Medienzu- 
griffssteuerungadresse verwendet wird und Bereitstellen der Meldung an die Anwendung. 
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Revendi cations 

1 . Un proc6cle pour faciliter la remise de contenu dans un flot de donndes de contenu d un terminal (24). ledit proc6d6 
comportant les stapes de : 

g§n6rer un descripteur (60) pour le flot de donn6es de contenu. ledit descrlpteur (60) comprenant au moins 
une adresse destination, cette dite adresse destination au moins comportant une adresse de contrdle d'accds 
aux supports multidiffusion au moins ; et . 

transmettre le descripteur au terminal (24) dans une PMT (Program Map Table) (54) ; 

situer le flot de donn6es de contenu en utilisant I'adresse destination dans le descripteur (60) au niveau dudit 
terminal (24). 

2. Le proced6 de la revendication 1 comprenant de plus I'etape de : 

extraire un message correspondent au contenu identifie provenant du flot de donnees de contenu. 

3. Le proc6d6 de la revendication 1 dans lequel le service de donnees est transmis au terminal dans un flot de 
transport MPEG-2 (Moving Pictures Expert Group-2). 

4. Le precede de la revendication 3 dans lequel le contenu est compatible avec une speciflcation ATVEF (Advanced 
Television Enhancement Forum) pour une programmation television avancee. 

5. Le proc6de de la revendication 4 dans lequel le contenu ATVEF est v6hicule en utilisant le protocole UDP (User 
Datagram Protocol) et le protocole IP (Internet Protocol) ledit proc6d6 comportant de plus les eta pes de : 

encapsuler des datagrammes IP dans une forme capable d'etre v6hicul6e dans un flot de transport MPEG- 
2;et 

transmettre les datagrammes IP encapsul6s au terminal (24) dans le flot de transport. 

6. Le procede de la revendication 5 dans lequel r6tape de transmission comporte la sous-etape de : 

multidiffuser les datagrammes encapsul6s a une plurality de terminaux compreniant ledit terminal (24). 

7. Le precede de la revendication 5 dans lequel ladite forme correspond a une specification DVB-MPE (Digital Video 
Broadcasting/Multi-Protocol Encapsulation) pour des sections de datagramme. 

8. Le precede de la revendication 5 dans lequel ladite forme correspond a une specification ATSC (Advanced Te- 
levision Systems Committee) pour des preoccupations adressables. 

9. Le procede de la revendication 6 comprenant de plus les etapes de : 

executor une application sur le terminal (24) configure pour utiliser le contenu ; 

demander une connexion e une adresse IP multidiffusion ou le contenu peut etre situe ; et 

mapper I'adresse IP multidiffusion e une adresse de controle d'acc6s aux supports multidiffusion correspon- 
dante. 

10. Le procede de la revendication 9 dans lequel ladite etape de situer le flot de donnees de contenu comprend les 
sous-etapes de : . 

extraire cette dite adresse de controle d'acces aux supports multidiffusion au moins comprise dans le des- 
cripteur provenant de la PMT (Program Map Table) (54) ; et 

determiner si I'adresse de contrdle d'acces aux supports multidiffusion mappee est comprise dans cette adres- 
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se de contrdle d'acces aux supports multidiffusion au moins extraite. 

11. Le proc6d6 de la revendlcation 10 comprenant de plus I'^tape de : 

extraire un message correspondant au contenu ATVEF lorsque I'adresse de controle d'acces aux supports 
multidiffusion mapp6e est comprise dans cette adresse de controle d'accds aux supports multidiffusion au 
moins extraite. 

12. Le proc6de de ia revendlcation 11 comprenant de plus I'etape de : 

fournir, par le biais de rapplication, un service audiovisuel am6lior6 conformement au message extrait, 

13. Le proc6d6 de la revendlcation 1, dans lequel le service de donnees est un service audiovisuel. et dans lequel le 
flot de donn6es de contenu et la PMT (Program Map Table) (54) sont associ6s au service audiovisuel. 

14. Le proc6d6 de n'importe quelle revendlcation precedente dans lequel ledit proc6d6 facillte la remise dudit flot de 
donnees de contenu audit terminal (24) au travers d'un flot de transport MPEG (Moving Pictures Expert Group) 
pour am6liorer un service de donn6es v^hicule par ledit flot de transport MPEG, ledit proc6de comprenant r6tape 
de : 

r6cup6rer un message provenant du flot de donn6es de contenu qui correspond au contenu en utilisjant I'adres- 
se destination cpmprise dans le descripteur (60). 

15. Le proc6de de la revendlcation 14 dans lequel le message est vehicul6 dans le m§me flot de service dudit flot de 
transport MPEG que le service de donnees. 

16. Le proc6d6 de la revendlcation 15 dans lequel le contenu comporte du contenu compatible ATVEF (Advanced 
Television Enhancement Forum). 

17. Un apparel! pour faciliter la remise d'un flot de donn6es de contenu comprenant du contenu au travers d'un flot 
de transport MPEG (Motion Pictures Expert Group) a un terminal (24) pour am6liorer un service audiovisuel. ledit 
appareil comportant : 

. une memoire configur^e pour stocker une adresse IP multidiffusion associ^e audit flot de donnees de contenu ; 
et 

un processeur configure pour generer un descripteur d'adresse (60) destind d dtre compris dans une PMT 
(Program Map Table) (54), 

ledit descripteur (60) comprenant au moins une adresse destination generee conformement a ladite adresse 
IP multidiffusion ; dans lequel 

cette dite adresse destination au moins comporte au moins une adresse destination de contrdle d'acces aux 
supports multidiffusion. 

18. Un terminal comportant : 

une application configur^e pour demander une connexion a une adresse IP multidiffusion pour recevoir du 
contenu configure pour am^liorer un service de donnees ; 

un moyen pour examiner une PMT (Program Map Table) (54) associ6e audit service audiovisuel pour d6ter- 
miner la presence d'un descripteur d'adresse (60), ledit descripteur d'adresse (60) comprenant une adresse 
de contrdle d'acces aux supports multidiffusion ; et 

un moyen pour recup6rer un message correspondant audit contenu lorsqu'utilisant ladite adresse de controle 
d'acces aux supports multidiffusion et fournir ledit message a ladite application. 
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